S3 Event-Driven Invocation of Lambda
Amazon S3 can trigger a Lambda function automatically in response to specific events like object uploads, deletions, or updates. This allows developers to build serverless, event-driven architectures where file operations directly invoke backend logic without manual polling.
s3:ObjectCreated:* – triggers when an object is uploaded or copied
s3:ObjectRemoved:* – triggers when an object is deleted
s3:ObjectRestore:* – triggers when an archived object is restored
s3:Replication:* – triggers when an object is replicated
Go to the S3 bucket in the AWS Console
Select the 'Properties' tab and find 'Event notifications'
Create a new event and specify the event type (e.g., ObjectCreated)
Choose 'Lambda function' as the destination
Select the Lambda function and grant it permission to be invoked by S3
You need to run a Lambda function every time a new object is uploaded to an S3 bucket. Walk me through the steps you would take to set that up.
If you accidentally set the event notification on the wrong prefix, what would happen when objects are added elsewhere in the bucket?
Our team noticed that a Lambda function isn’t being invoked for certain S3 PUT events. How would you troubleshoot the issue?
Explain the trade‑offs between using S3 event notifications versus S3 Object Lambda for processing new objects.
Design a solution to reliably process millions of S3 object creation events per hour with Lambda, ensuring ordering and handling throttling.
How would you secure cross‑account S3 to Lambda triggers while minimizing permissions and avoiding circular dependencies?
We are migrating a legacy data pipeline that currently uses S3 notifications to trigger a fleet of Lambda functions across multiple regions. What architectural changes would you recommend to improve scalability, observability, and fault tolerance?
Discuss the long‑term maintenance implications of using S3 event notifications versus an event‑bus (e.g., EventBridge) for triggering Lambda, especially in a multi‑team environment.